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structure that is inter-linked with the other directories. This structure must be maintained to assure consistency and 
compatibility between projects to clarify project differences, and architecture updates. 

The _Arch directory stores many of the most common parts of the system architecture. These files generally do not 
change and can be reused in any area of the project. If there is common visual basic code for applications that will 
continuously be used in other applications, the flies will be housed in a folder in this directory. The sub-directories in the 
_Arch directory are broken into certain objects of the main project. Object in this case refers to parts of a project that are 
commonly referred to within the project. For example, modules and classes are defined here, and the directory is analogous 
to a library of functions, APIs, etc... that do not change. For example the IcaObj directory stores code for the Intelligent 
Coaching Agent (ICA). The InBoxObj directory stores code for the InBox part of the project and so on. The file structure uses 
some primary object references as file directories. For example, the IcaObj directory is a component that contains primary 
objects for the ICA such as functional forms, modules and classes. The BrowserObj directory contains modules, classes and 
forms related to the browser functionality in the architecture. The HTMLGIossary directory contains code that is used for the 
HTML reference and glossary component of the architecture. The IcaObj directory contains ICA functional code to be used in 
an application. This code is instantiated and enhanced in accordance with a preferred embodiment. The InBoxObj directory 
contains code pertaining to the inbox functionality used within the architecture. Specifically, there are two major components 
in this architecture directory. There is a new .ocx control that was created to provide functionality for an inbox in the 
application. There is also code that provides support for a legacy inbox application. The PracticeObj directory contains code 
for the topics component of the architecture. The topics component can be implemented with the HTMLGIossary component 
as well. The QmediaObj directory contains the components that are media related. An example is the QVIDctri^pThe 
QViDctrl is the code that creates the links between QVID files in an application and the system in accordance with a 
preferred embodiment. The SimObj directory contains the Simulation Engine, a component of the application that notifies the 
tutor of inputs and outputs using a spreadsheet to facilitate communication. The StaticObj directory holds any component 
that the application will use statically from the rest of the application. For example, the login form is kept in this folder and is 
used as a static object in accordance with a preferred embodiment. The SysDynObj directory contains the code that allows 
the Systems Dynamics Engine (Powersim) to pass values to the Simulation Engine and return the values to the tutor. The 
VBObj directory contains common Visual Basic objects used in applications. For example the NowWhat, Visual Basic 
Reference forms, and specific message box components are stored in this folder. The Jools directory contains two main 
directories. They represent the two most used tools in accordance with a preferred embodiment. The two directories provide 
(he code for the tools themselves. The reason for providing the code for these tools is to allow a developer to enhance 
certain parts of the tools to extend their ability. This is important for the current project development and also for the growth of 
the tools. The Icautils directory contains a data, database, default, graphics, icadoc, and testdata directory. The purpose 
of all of these directories is to provide a secondary working directory for a developer to keep their testing environment of 
enhanced Icautils applications separate from the project application. It is built as a testbed for the tool only. No application 
specific work should be done here. The purpose of each of these directories will be explained in more depth in the project 
directory section. The TestData folder is unique to the Jools/ICAUtils directory. It contains test data for the regression bench 
among others components in ICAUtils. 

The Utilities directory holds the available utilities that a Business Simulation project requires for optimal results. 
This is a repository for code and executable utilities that developers and designers may utilize and enhance in accordance 
with a preferred embodiment. Most of the utilities are small applications or tools that can be used in the production of 
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with Target objects^piiike the Source to Sourceltem relationship). In the journalization example, there is one journal entry - 
for each of the twenty-two transactions. For each journal entry there is a corresponding TargetPage object that contains the 
Debits Target and Credits Target for that journal entry. 

As the student manipulates the application interface, each action is reported to the ICAT. In order to tell the ICAT 
what actions were taken, the application calls to a database and asks for a specific interface control's ID. When the 
application has the ID of the target control and the Sourceltem control, the application notifies the ICAT about the Target to 
Sourceltem mapping. In other words, every time a student manipulates a source item and associates it with a target (e.g., 
dragging an account name to a debit line in the journal), the user action is recorded as a mapping of the source item to the 
target. This mapping is called a UserSourceltemTarget. Figure 21 illustrates the mapping of a source item to a target item in 
accordance with a preferred embodiment. When the student is ready, he submits his work to one of the simulated team 
members by clicking on the team member's icon. When the ICAT receives the student's work, it calculates how much of the 
work is correct by concept. Concepts in our journalization activity will include Debits, Credits, Asset Accounts, etc. For each 
of these concepts, the ICAT will review all student actions and determine how many of the student actions were correct In 
order for the ICAT to understand which targets on the interface are associated with each concept, the targets are bundled 
into target groups and prioritized in a hierarchy. Once all possible coach topics are activated, a feedback selection analyzes 
the active pieces of remediation within the concept hierarchy and selects the most appropriate for delivery. The selected 
pieces of feedback are then assembled into a cohesive paragraph of feedback and delivered to the student Figure 23 
illustrates a feedback selection in accordance with a preferred embodiment. After the ICAT has activated CoachTopics via 
Rule firings, the Feedback Selection Algorithm is used to determine the most appropriate set of Coachltems (specific pieces 
of feedback text associated with a CoachTopic) to deliver. The Algorithm accomplishes this by analyzing the concept 
hierarchy (TargetGroup tree), the active CoachTopics, and the usage history of the Coachltems. Figure 24 is a flowchart of 
the feedback logic in accordance with a preferred embodiment. There are five main areas to the feedback logic which 
execute sequentially as listed below. First, the algorithm looks through the target groups and looks for the top-most target 
group with an active coach topic in it Second, the algorithm then looks to see if that top-most coach item is praise feedback. 
If it is praise feedback, then the student has correctly completed the business deliverable and the ICAT will stop and return 
that coach item. Third, if the feedback is not Praise, then the ICAT will look to see if it is redirect, polish, mastermind or 
incomplete-stop. If it is any of these, then the algorithm will stop and return that feedback to the user. Fourth, if the feedback 
is focus, then the algorithm looks to the children target groups and groups any active feedback in these target groups with the 
focus group header. Fifth, once the feedback has been gathered, then the substitution language is run which replaces 
substitution variables with the proper names. Once the ICAT has chosen the pieces of feedback to return, the feedback 
pieces are assembled into a paragraph. With the paragraph assembled, the ICAT goes through and replaces all variables. 
There are specific variables for Sourceltems and Targets. Variables give feedback specificity. The feedback can point out 
which wrong Sourceltems were placed on which Targets. It also provides hints by providing one or two Sourceltems which 
are mapped to the Target. 

The Steps Involved in Creating Feedback in Accordance With A Preferred Embodiment 
The goal of feedback is to help a student complete a business deliverable. The tutor needs to identify which 
concepts the student understands and which he does not. The tutor needs to tell the student about his problems and help 
him understand the concepts. There are seven major steps involved in developing feedback for an application. First, creating 
a strategy — The designer defines what the student should know. Second, limit errors through interface — The designer 
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from the simulation model; invoking the Runlnputs, RunOutputs and RunLists methods of the simulation engine object in 
order to bring the ICA to it's original state; calling the Submit method of the ICA object with zero as argument to trigger all the 
rules; calling the SetDirtyFlag of the ICA object with 0 and false as arguments in order to reset the user's session. Running 
inputs involves going through the list of TutorAware inputs and notifying the ICA of the SourceltemID, TargetID and Attribute 
value of every input. Running lists involves going through the list of TutorAware lists and notifying the ICA of the 
SourceltemID, TargetID and Attribute value of every item in every list. The TargetID is unique for every item in a list 
Running outputs involves going through the list of TutorAware outputs and notifying the ICA of the SourceltemID, TargetID 
and Attribute value of every output. Modification stage 1. Reading inputs & outputs; Code: Dim sDataArray(2) as string; 
Dim vAttribute as variant; Dim ISourceltemID as long; Dim ITargetlD as longJRet = 
moSimEngine.ReadReference("DistincUnput°, vAttribute, ISourceltemID, ITargetlD, sDataArray) 

Description: The ReadReference method of the simulation object will return the attribute value of the input or 
output referenced by name and optionally retrieve the SourceltemID, TargetID and related data. In the current example, the 
attribute value, the SourceltemID, the TargetID and 3 data cells will be retrieved for the input named Distmctjnput 

Description: The simulation engine object provides basic functionality to manipulate lists. 

The UstAdd method appends an item(SourceltemlD, Attribute, Data array) to the list. Let's explain the algorithm. 
First, we find the top of the list using the list name. Then, we seek the first blank ceil underneath the top cell. Once the 
destination is determine, the data is written to the appropriate cells and the ICA is notified of the change.The ListCount 
method returns the number of items in the specified list. The algorithm works exactly like the UstAdd method but returns the 
total number of items instead of inserting another elemenLThe ListModify method replaces the specified item with the 
provided data. Let's explain the algorithm. First, we find the top of the list using the list name. Second, we calculate the row 
offset based on the item number specified. Then, the ICA is notified of the removal of the existing item. Finally, the data 
related to the new item is written to the appropriate cells and the ICA is notified of the change. The ListDelete method 
removes the specified item. The algorithm works exactly like the ListModify method but no new data is added and the cells 
(width of the list set by 'Total Columns') are deleted with the 'move cells up' parameter set to true. Keep this in mind, as 
designers often enter the wrong number of columns in the Total Columns parameter. When they overestimate the Total 
Columns, ListDelete will modify portions of the neighboring list, which leads to erratic behavior when that list is displayed. 

SYSTEM DYNAMICS IN ACCORDANCE WITH A PREFERRED EMBODIMENT 

To use system dynamics models in the architecture, an engine had to be created that would translate student work 
into parameters for these models. A complex system dynamics model to interact with an existing simulation architecture is 
discussed below. The system dynamics model provides the following capabilities.Aliow designers to build and test their 
system dynamics models and ICA feedback before the real interface is builLReduce the programming complexity of the 
actJvifies.Centralize the interactions with the system dynamics models.System Dynamics Engine As with the simulation 
engine, the designer models the task that he/she wants a student to accomplish using a Microsoft Excel spreadsheet. Here, 
however, the designer also creates a system dynamics model (described later). The system dynamics engine will read all of 
the significant cells within the simulation model (Excel) and pass these values to the system dynamics model and the ICA. 
After the system dynamics model runs the information, the output values are read by the engine and then passed to the 
simulation model and the ICA 
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ModelDesc 


0 




SysDynModel 


String '5 

0 


Filename of the actual system dynamics model 


Start 


Long 


Start time to play modal 


Stop 




Stop time to play model 


Step 


Long 


Interval at which to play one model step and record data 



This information is stored in the model table of the simulation database (ICASim.mdb). All of the values that will 
need to be manually entered by the student that are passed into the system dynamics model are configured as parameter 
inputs (Plnputs) objects. Every Plnput has an interface as detailed below. 



Field Name 


Data Type 


Description 


PinputID 




Primary Key for the table 


TasklD 




TasklD of the task associated with the parameter input 


ModellD 




ID of the model associated with the parameter input 


InputName 


string'50 


Name of the parameter input (informational purposes) 


InputOesc 


string*255 


Descnption (informational purposes) 


ReferenceName 


string'50 


Name of the spreadsheet cell associated with the parameter input' 


SimReferenceName 


string'50 


Name of the associated parameter in the system dynamics model 


TutorAware 


boolean 


Whether the ICA should be notified of any input CHANGES 


SourceltemID 


m 


SourceltemID of the parameter input 


Target© 


long 


TargetlD of the parameter input 


Row 


long 


Spreadsheet row number of the parameter input 


Column 




Spreadsheet column number of the parameter input 


SheetName 


stnng'50 


Sheet name were the parameter input is located 



All of this information is stored for every parameter input in the Plnput table of the simulation database 
(ICASim.mdb). Plnputs consist of one spreadsheet cell that can be populated by a designer at design time or by the GBS 
application at run time via the system dynamics engine object's methods. The purpose of the cell is to provide an entry point 
to the simulation and system dynamics models. An example of an entry point would be the interest rate parameter in the 
interest calculation example. The ICA is notified of any changes to the cell when an appropriate activity transpires. When the 
ICA is notified of a change two messages are sent to the ICA. The first is an ICANotifyDestroy message with the parameter 
input information i.e., SourceltemID, TargetlD and null as an attribute. This message is sent to inform the ICA to remove 
information from its memory. The second message is an ICANotifyCreate message with the parameter input information i.e., 
SourceltemID, TargetlD, Attribute (cell numeric value). This message advises the ICA to add this information to its memory. 
A Plnput table record in accordance with a preferred embodiment is presented below. 

PinputID: I 12345 _ *~~" 

__ _ 

____ - 

InputName: Interest Rate input 
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